Skip Ribbon Commands
Skip to main content

As an alternative to running interactive forms within ContactsLaw, it is also possible to access them via the web*. This is implemented as an extension to the REST API, which requires the ContactsLaw Daemon to be configured appropriately.

Web forms are designed to work on existing designs without the need for modifications, however some functionality simply isn't possible through this method.

* In this context, the term 'web' refers to access via a web browser. You may choose whether to make forms available on the Internet, or restrict access to your local network/VPN only.

Requirements

In order to access interactive forms over the web, you must be using the ContactsLaw Daemon. You must also enable REST API access via system settings.

If external access is required, you will need to configure port forwarding. The use of HTTPS/SSL/TLS is also strongly recommended.

Endpoints

The URL for a web form can be obtained using the 'Copy URL for Web Form' command on the Tools menu in the designer. This does not include the hostname and port number, as these can change depending on your network configuration. These are always the same as for the REST API.

All web form URLs are in the following format: https://hostname/Extensions/FormsFramework/Form/1234 where the trailing number is unique to the form design.

Authentication

By default, web forms require users to log in using their ContactsLaw username and password. Thereafter, they behave as if running on that user's PC.
 
You can also configure anonymous (public) access to forms via the Security - Access Level property of the form. You must ensure that the service account used by the ContactsLaw Daemon has sufficient permissions to complete the form. Any actions performed by the form are done so using that account.

Design considerations

Responsive design

Unlike forms that run within ContactsLaw, the designer has little to no control over the size/shape of the display on which a web form runs. For this reason, you should try to avoid manually setting the location and size of controls and instead use responsive layouts. Elements of an effective responsive layout include:

  • Using a table layout (columns and rows) on each page of the form
  • Using 'Stack' or 'Fill' as the default layout for sections
  • Selecting fonts which are available on all devices and platforms (see this link) or use Google Fonts

Forms which have a large header/footer (and are likely to be viewed on mobile devices) may benefit from the Responsive Scrolling option, which scrolls the header and footer with the rest of the form instead of keeping them separate on the screen.

Pages with multiple columns which may not fit the width of the screen may benefit from the Responsive Pivoting option, which allows rows to break onto multiple lines.

Other considerations for web forms include keeping image files small, as well as using comments and tooltips to improve the user experience. It is a good idea to test the form on several browsers, platforms and devices to ensure that the design is robust.

Functional limitations

Some types of components do not work on web forms, as they do not run within ContactsLaw:
  • Contact, file and document picker controls
  • Table controls
  • Custom field controls
  • Actions which open contact or file tabs
  • Actions which print or preview the form
  • Actions which set journal notes
  • Actions which start activities

Note that you can still use these components, but they will either appear as placeholders or have no effect. You can hide or skip over them using rules.

Captchas

Web forms which are publicly accessible (without a login) may be vulnerable to nuisance (spam) or malicious attacks. To mitigate this, you can add a captcha control to the form which requires the user to prove that they are not a robot. You will need to register a Google reCAPTCHA account and enter the site key and secret key into the control's properties.

Presenting the captcha to the user on the last page of the form (prior to completion) is recommended to offer the best end-user experience. However, forms which perform intensive operations or create records prior to their completion may require the captcha to be shown earlier in their flow.

Finish behaviour

While forms that run within ContactsLaw simply close upon completion, it is generally more desirable for web forms to end on a static page. This can be achieved by changing the Finish Behaviour property to 'Go to last page' and then hiding the last page of the form under normal conditions. Note that a page shown in this manner may NOT modify any of the form's data or perform additional actions.
 
You can also configure the form to restart upon completion, which is more useful for bulk data entry forms. 

See also